如何開始進行團隊的FID，我們先別急，先來看看目前的情況。

首先每個組織或公司，都有自己專屬的業務領域，在多數情況下，這個業務領域可以分拆出幾個功能區塊，例如：

領域分類

如果妳是漢堡店，那麼就可以拆分為

• 麵包小組、醬料小組、肉類小組、飲料小組

如果是一家接案公司，那麼就可以拆分為

• CMS 小組、品牌小組、特效小組、遊戲小組、APP 小組、模板小組

而大部分的公司都可以拆分為

• 內部系統小組
• CMS 網站小組

以某個支付公司為例，可以拆分為，我就分拆出幾個小組，分別包括，

• 內部系統小組
• 行銷網站小組
• 跨平台小組
• UI 小組
• 第三方小組

每個小組都會有自己研究的議題和非專案任務，例如：

• 研究如何將系統改成跨平台
• 探究如何將系統改成微前端
• 快速開發網站的方法，例如設計 no code 平台
• 研究如何將 CMS 拆分出 headless CMS
• ...

最後我們將會集中資源去研究和開發，並且將這些研究成果，整合到專案中。

收集資料

在開始分類之前，我們需要先整理過去做過的專案，將其分析和歸納，並且將其分類，例如：

• 現金流管理系統：CMS 系統，後台 UI，權限管理，檔案管理
• 第三方插件管理系統：CMS 系統，後台 UI，權限管理
• 購物節網站：行銷網站，遊戲，快速開發
• API 管理系統：CMS 系統，後台 UI，權限管理，serverless

將每個專案進行標籤化分類，這樣我們就可以知道，每個專案所需要用到的領域是什麼，當分類越來越細，我們可以將每道工序進行專精化，以下是一些前端專精化的研究項目：

分類的方式

• 從功能面向分類：對他的目的和功能進行分類，例如：CMS、行銷網站、內部系統、第三方系統
• 從流程面向分類：例如開發流程需要的步驟，部署作業，測試作業，維護作業
• 從危機面向分類：例如維護成本高的部分，緊急需求時的應對措施
• 從使用者面向分類：例如使用者的需求，內部使用者，外部使用者，合作夥伴
• 從技術面向分類：例如技術的特性，工程師使用的習慣，協作的方法
• 從突破面向分類：如果研究成功，可以大幅度減少開發時間，或是大幅度提升開發效率，或者對公司的業務有幫助

依據每個情況和資源，你總能在這些面向中找到可以突破的地方。

對分類進行優先排序

當我們有了一堆標籤之後，但我們只有四個人，或者更少，我們可以如何分配資源呢？

最簡單的方式，莫過於對這些待研究的項目進行優先排序，例如：

排序的緯度有兩個：

• 緊急性：這個項目是否緊急，是否有人在等待
• 重要性：這個項目是否重要，如果沒有完成，後果是什麼

按照這兩個維度，我們可以將項目分成四個區塊，優先順序如下

我知道大家想說什麼，那就：

「我有做不完的事情，我都是緊急且重要的」

你完全正確，那麼接下來就是展示技術的時候了，每個團隊都有這樣的情況，那我們需要用一些方法消化掉這些事情，依據以下兩個屬性。

• 成本：這個項目是否成本高，是否需要大量的資源，大量的時間和人力，可能還需要大量的研究，且不一定能成功
• 穩定性：這個項目是否穩定，是否有技術轉移風險，它能否穩定的運作多久，如果壞了，怎麼辦

消化掉緊急且重要的事

• 緊急且重要： 採用穩定高，成本低的方法
• 不緊急但重要：採用成本高，但是可以獲得技術回饋的方法

每次都要得到「技術回饋」，並將這個方法套用在「緊急且重要」的事情上。

低成本的陷阱

例如公司需要一個官方網站，我們採用了保險且穩定的方法，例如用 Wordpress。

這是一個穩定度高且成本低的策略。

但是，當我們隨著時間增長，客戶需求越來越多，這個網站需要有一些特殊的功能，例如：

• 有一個可以針對文章做同步的功能
• 有一個前台可以同步其他網站的功能

假設 Wordpress 沒有這個功能，於是我們要自行開發，這就變成「高成本的方案」了。

結合上面兩個觀點

按照事情的優先度，我們得出以下的結論：

1. 緊急的事情很多：表示我們的技術沒有跟上
2. 採用低成本的次數越多：我們遇到的緊急事情就越多
3. 採用高成本的次數越多：我們遇到的緊急事情就越少

按照每個團隊和組織的情況，來進行任務的分配，假設如果大家都在做低成本的事情，這個團隊勢必走向大家都忙死的結局，而且這個團隊的技術也不會有成長。

我建議團隊中，至少需要 2 位資深和技術能力好的工程師來帶領至少一個的專業領域，並用其「技術回饋」來解決「緊急且重要」的事情。

總結步驟

1. 收集資料，進行分類標籤化
2. 細分專業領域，你可能會分出很多個，可能有20～30個
3. 優先選擇能解決多數緊急事情的專業領域，鎖定1～2個領域
4. 研究出成果，反饋在日常的工作上。